home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Feb 91 / MacApp.Tech$ 2⁄15⁄91 / 2918-Re (long)C++⁄MacApp -Feb91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.5 KB  |  90 lines  |  [TEXT/GEOL]
  1. Item    5202852                         10-Feb-91        15:54GMT
  2.  
  3. From:   UK0392                          EHN & DIJ Oakley,BDV
  4.  
  5. To:     DAWSON.M                        Dawson, Mark
  6.         MACAPP.TECH$                    MacApp Technical
  7.  
  8. ------------------------------------------------------------------------------
  9.  
  10. Sub:    Re: (long)C++/MacApp 3.0 comme
  11.  
  12. Mark and friends,
  13.  
  14. Thank you for trying to allay our fears about the impending conversion of
  15. MacApp into C++.  I am afraid that many of your points do the exact opposite!
  16.  
  17. >(1) If you currently use the MPW enviroment, there will be ALMOST NO AFFECT on
  18. >you.  The MacApp team WILL make the 3.0 link-compatible with Object Pascal.
  19. I am afraid that I do use the MacApp source a great deal, and on occasion have
  20. been known to derive my code from it or even to modify it.  This will be
  21. largely lost to me - I have not yet even found time to read the C++ manual
  22. (vast as it is).  I am suspect that, if any benefit is to accrue to MacApp, it
  23. will end up being more powerful when used with C++ than from OP - just as C++
  24. folk are currently second-class MacAppers, so OP users will be henceforth.
  25. Just as my customers are not prepared to be second class, neither can I.
  26.  
  27. >They also said they would shy away from using pieces of C++ that, though may
  28. >be more efficient, would be harder to read for non-C/C++ programmers.
  29. Catch 22, MacApp will be stunted deliberately.
  30.  
  31. >(3) SourceBug, a new source-level debugger that is supposed to be available
  32. >(in an Alpha version) on the ETO #3 disk, seems to be very similar to the
  33. >Think-Pascal debugger.
  34. Great, an alpha debugger to use with my beta MPW to try to produce stable
  35. release code - presumably we will have many months of MacApp 3.0 betas as well?
  36. Where does this put folk having to ship real products for System 7 release?
  37.  
  38. >(4) The MacApp team promised to make available documentation and MPW scripts
  39. >describing what and how to convert from Object Pascal to C++ (if you decide
  40. >that's the way to go).
  41. I still think that (even assuming that I learned C++ overnight) porting my 8+
  42. megabytes of OP source will cause a great deal of grief, and a hiatus that we
  43. cannot accept.
  44.  
  45. >(5) Apple did promise to help out Think Pascal users; what form that might
  46. >take was not discussed.
  47. This smacks of the politician's answer, to a question that they had not yet
  48. anticipated let alone tackled.
  49.  
  50. >(6) Steve Jasik (of "The Debugger" fame) said that it would be difficult to
  51. >provide the same level of debugging for a C++ MacApp that he can for an
  52. >Object-Pascal one.
  53. Great, let's kill another invaluable tool, and finish off someone else who has
  54. made a vital contribution to Mac development.
  55.  
  56. >(10) Eric Berdahl agreed to do a series of articles that will appear in
  57. >Frameworks that will explain how to read C++, convert from Object Pascal to
  58. >C++, and eventually some of the nice things you can do in C++.
  59. Much appreciated, and there is no shortage of books on C++ to supplement the
  60. vast Apple C++ manual.  Will someone offer to come and do it all for me, or at
  61. least fund the conversion, and all the beta testing?
  62.  
  63. >(11) By using C++, MacApp 3.0 programs are currently (thinks could change) a
  64. >little SMALLER than their 2.0 counterparts (so it looks like MacApp may have
  65. >stopped growing).
  66. I'll believe that when I see it - ever since we started on the MacApp kick,
  67. with 1.1.1, every new version has seen an almost exponential increase in source
  68. size, and an increase in executable size too.  I do not worry so much about
  69. that.  What does worry me is code maintainability, code reliability, and code
  70. readability.  I will be interested to hear of anyone who can claim that C++
  71. will improve any of those.
  72.  
  73. I see portability increasingly cited as a reason to use C++ (although of course
  74. in the last year or so OP has actually been implemented on the PC as well).
  75. This is only useful in the context of MacApp *if* MacApp is ported to other
  76. platforms.  Now, *if* that were to happen, it would only be of much value if
  77. the other platforms included PCs under Windows - in which case, I think very
  78. few products would ever debut on the Mac, and only a small fraction would even
  79. be ported.  Offering MacApp on other platforms would be giving away what to me
  80. is at least a goodly part of the Crown Jewels - and moving it into C++ is
  81. melting them down and trying to refashion them!
  82.  
  83. Would anyone be interested in starting an independent and co-operative MacApp
  84. 3.0 development in Object Pascal?  I am not sure how we would need to licence
  85. it, but it might be a much better answer to our problems than the official
  86. version.
  87.  
  88. Regards, Howard.
  89.  
  90.